Due to the threat of illegal recording of broadcast content, there is a trend to move security endpoints closer to the actual point of usage, in order to prevent interception and possible distortion/disruption of the broadcast information before it reaches the end user. An example of this could for instance be when an end user watches a TV show on his laptop, and at the same time listens to the sound in his headphones. In this case, it is desired that both the video stream and the audio stream is encrypted all the way to the endpoint, i.e., the video stream should be decrypted close to the screen and the audio stream should be decrypted inside the headphones.
Another, and somewhat conflicting requirement, is that there in future networks will exist a need to allow intermediate media routers to be able to modify the content, e.g., to allow for different codecs (coders/decoders). Not all media routers are however trusted to the same degree, and they therefore have different access rights. One such example is when certain media routers are allowed to have access to both the media integrity and confidentiality keys, a second set of routers are only allowed to have access to the media integrity keys, and a third set are not allowed to have access to any keys at all. To change the cryptographic state of media routers of different degrees of trust (i.e. having different access to broadcast information), thus requires separate treatment of said routers. Contrary to the endpoints discussed above, the access to the media keys should in the intermediate media routers be irrespective of whether it is a video or an audio stream that is accessed, only the degree of trust is important for the routers.
Moreover, it is desired to be able to treat the end point devices and the media ports as different groups. One reason for this desire, is that it provides good security practice. In addition, since it is likely that they will differ in user behaviour and, not treating them as different groups, may otherwise impact scalability in a bad way. These security problems/requirements of future media delivery technologies discussed above are for example mentioned in [1].
Broadcast encryption is often directed towards media delivery, since historically media delivery has been on a broadcast basis. Examples of broadcast media are radio-based TV and radio and traditional newspapers. However, there can be other applications as well where broadcast encryption is used as a tool to facilitate information collection, such as for collection and processing of data from sensors.
Known methods to make broadcast encryption more efficient, e.g., Logical Key Hierarchy (LKH) [2] and Subset Difference (SD) [3], are useful for forming user groups and for providing these with group keys. Each such method has characteristics suitable for specific group characteristics. Exemplary, SD is useful if the group is highly dynamic in terms of the number of joining and/or leaving group members.
It is often desired to form new sub-groups from two or more prevailing (super) groups. However, a disadvantage of known methods for key management is that each instance of the broadcast encryption protocol must be managed for each such new group causing a scaling problem.
Broadcast Encryption
Group security deals with the problem of establishing an up to date cryptographic state among a group of users. When a group security scheme is used in a broadcast setting, the scheme is called a broadcast encryption scheme. In most broadcast encryption protocols the existence of a central role controlling the group and managing all the cryptographic keys is assumed. This central role is referred to as the Group Controller/Key Server (GCKS).
A common way to utilise a broadcast encryption scheme is to first broadcast a header containing a cryptographic key KM encrypted in such a way so that only the entitled receivers can decrypt the header. The actual message (e.g. a media stream) M is then protected using this cryptographic key KM. The header could be encrypted in a “naïve” way, where every member of the group shares an individual secret key together with the GCKS. Whenever the cryptographic state is to be changed, the GCKS transmits the new state to each remaining member in the group protected under the key shared with that particular member. When the size of the broadcast is mentioned in this application, then it is normally the size of the header and not to the size of the message M that is referred to, since the size of the message M is independent of which broadcast encryption protocol that is used. The problem with the above described naïve solution is that the header will contain as many messages as members in the group, and this is not acceptable in large groups, since it will require too large broadcast size. A pictorial view of the traditional naïve method is given in FIG. 1. Here, the circles denote a user ui who shares the key Ki with the GCKS.
Due to the large broadcast size in the naïve method, new protocols that are more effective have been developed. These methods include for example the Logical Key Hierarchy (LKH) protocol, as described in [2], which makes the change of the cryptographic state, or the transmission of the header, more efficient. The LKH protocol is suitable for small group systems in which only small changes of the group patterns occur. Another example of a more efficient protocol is the Subset Difference (SD) protocol, as described in [3]. The SD protocol is useful to use in groups with very large membership fluctuations between each update interval. None of the described protocols are however efficient enough to be used in practice due to the large broadcast size. The limiting parameters are the size of the group, the required updating intervals, group characteristics and existing bandwidth.
Key Management for Access Hierarchies
There has recently been published a number of articles on key-management for access hierarchies with different degree of sophistication. In [4], a simple method for managing group keys in a hierarchical way along one dimension was introduced. The benefit from using this method is that one minimizes the required memory on both the server and receiver side. In [5] on the other hand, a much more advanced solution was presented. This solution allows a user to compute keys corresponding to an access hierarchy based on any directed graph with only a minimum of secret keys. On the backside compared to the solution in [4], a user needs to store data proportional to the size of the graph. A solution similar to [5] but simpler was described in [6], where one instance of a GKM scheme is used to deliver a group key, and then a hash function and a long term secret are used to differentiate between different sub groups.
Problems with Existing Solutions
The scenario described above, with security endpoints very close to the media rendering device and intermediate media routers, requires very frequent updates and multiple key transmissions (in the described example FIG. 3, both the integrity and the confidentiality key of both the audio and video stream need to be broadcast) in order to fulfil the requirements. In addition, it is desired to treat the group of media ports and end point devices as different groups with no apparent relationship between their respective keys to maintain a good security policy. No known methods for group key management such as LKH and SD and/or in combination with key management for access hierarchies can achieve this in an efficient way.